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Abstract. We present a new free library for Constraint Logic Program- 
ming over Finite Domains, included with the Ciao Prolog system. The 
library is entirely written in Prolog, leveraging on Ciao's module system 
and code transformation capabilities in order to achieve a highly modu- 
lar design without compromising performance. We describe the interface, 
implementation, and design rationale of each modular component. The 
library meets several design goals: a high level of modularity, allowing 
the individual components to be replaced by different versions; high- 
efficiency, being competitive with other TT> implementations; a glass-box 
approach, so the user can specify new constraints at different levels; and 
a Prolog implementation, in order to ease the integration with Ciao's 
code analysis components. The core is built upon two small libraries 
which implement integer ranges and closures. On top of that, a finite do- 
main variable datatype is defined, taking care of constraint reexecution 
depending on range changes. These three libraries form what we call the 
TT> kernel of the library. This TT> kernel is used in turn to implement 
several higher-level finite domain constraints, specified using indexicals. 
Together with a labeling module this layer forms what we name the TV* 
solver. A final level integrates the CLP(J r D) paradigm with our TT> 
solver. This is achieved using attributed variables and a compiler from 
the CLP(_FX>) language to the set of constraints provided by the solver. 
It should be noted that the user of the library is encouraged to work in 
any of those levels as seen convenient: from writing a new range module 
to enriching the set of TT> constraints by writing new indexicals. 



1 Introduction 

Constraint Logic Programming (CLP) pQ is a natural and well understood ex- 
tension of Logic Programming (LP) in which term unification is replaced by 
constraint solving over a specific domain. This brings a number of theoretical 
and practical advantages which include increased expressive power and declar- 
ativeness, as well as higher performance for certain application domains. The 
resulting CLP languages allow applying efficient, incremental constraint solv- 
ing techniques to a variety of problems in a very natural way: constraint solving 



blends in elegantly with the search facilities and the ability to represent partially 
determined data that are inherent to logic programming. As a result, many mod- 
ern Prolog systems offer different constraint solving capabilities. 

One of the most successful instances of CLP is the class of constraint logic 
languages using Finite Domains (TV). Finite domains refer to those constraint 
systems in which constraint variables can take values out of a finite set, typically 
of integers (i.e., a range). They are very useful in a wide variety of problems, 
and thus many Prolog systems offering constraint solving capabilities include a 
finite domain solver. In such systems, domain (range) definition constraints as 
well as integer arithmetic and comparison constraints are provided in order to 
specify problems. 

Since the seminal paper of Van Hentenryck et al. |2J , many FD solvers adopt 
the so-called "glass-box" approach. Our FD Kernel also follows this approach, 
based on a unique primitive called an indexical. High-level constraints are then 
built /defined in terms of primitive constraints. An indexical has the form X in r , 
where r is a range expression (defined in ??). Intuitively, X in r constrains the 
TV term (TV variable or integer) X to belong to the range denoted by the term 
r. In the definition of the range special expressions are allowed. In particular, 
the expressions max(Y) and max(Y) evaluate to the minimum and the maximum 
of the range of the TV variable Y, and the expression dom(Y) evaluates to the 
current domain of Y. Constrains are solved partially in an incremental using con- 
sistency techniques [3] which maintain the constraint network in some coherent 
state (depending on the arc-consistency algorithm used) . This is done by mono- 
tone domain shrinking and propagation. When all constraints are placed and all 
values have been propagated a call is typically made to a labeling predicate which 
performs an enumeration-based search for sets of compatible instantiations for 
each of the variables that remain not bound to a single value. We refer to [2] for 
more details regarding indexicals and finite domain constraint solving. 

In this paper, we present a new free library for Constraint Logic Program- 
ming over Finite Domains, included with the Ciao Prolog system [4j. The li- 
brary is entirely written in Prolog, leveraging on Ciao's module system and code 
transformation capabilities in order to achieve a highly modular design with- 
out compromising performance. We describe the interface, implementation, and 
design rationale of each modular component. The library meets several design 
goals: a high level of modularity, allowing the individual components to be re- 
placed by different versions; high-efficiency, being competitive with other TV 
implementations; a glass-box approach, so the user can specify new constraints 
at different levels; and a Prolog implementation, in order to ease the integration 
with Ciao's code analysis components. The core is built upon two small libraries 
which implement integer ranges and closures. On top of that, a finite domain 
variable datatype is defined, taking care of constraint reexecution depending 
on range changes. These three libraries form what we call the TV kernel of 
the library. This TV kernel is used in turn to implement several higher-level 
finite domain constraints, specified using indexicals. Together with a labeling 
module this layer forms what we name the TV solver. A final level integrates 



the CLP (TV) paradigm with our FT) solver. This is achieved using attributed 
variables and a compiler from the CLV(J-V) language to the set of constraints 
provided by the solver. It should be noted that the user of the library is encour- 
aged to work in any of those levels as seen convenient: from writing a new range 
module to enriching the set of TT> constraints by writing new indexicals. 

One of the first CLP(J-T)) implementations is the CHIP system [5]. This 
commercial system follows a typical black-box approach: it consists of a complete 
solver written in C and interfaces in an opaque manner to a Prolog engine. This 
makes it difficult for the programmer to understand what is happening in the core 
of the system. Also, no facilities are provided for tweaking the solver algorithms 
for a specific application. 

More recent CLP(J-T)) systems such as those in SICStus [B|, GNU Pro- 
log |7I8) . and B-Prolog [9] are built instead following more the glass-box ap- 
proach. The basic constraints are decomposed into smaller but highly optimized 
primitives (typically indexicals). Consequently, the programmer has more lati- 
tude to extend the constraints as needed. However, even if such systems can be 
easily modified/extended at the interface level (e.g., both SICStus and B-Prolog 
provide way to define new global constraints) they are much harder to modify at 
the implementation level (e.g., it is not possible to replace the implementation 
of range). 

The Ciao CLP(J r 2?) library that we present has more similarities with the 
one recently developed for SWI Prolog [TU] . Both are fully written in Prolog and 
support unbound ranges. The SWI library is clearly more complete than Ciao's 
(e.g., it provides some global constraints and always terminating propagation), 
but it is designed in a monolithic way: it is implemented in a single file, mixing 
different language extensions (using classical Prolog term_expansion mecha- 
nisms) while the Ciao library is split in more around 20 modules with a clear 
separation of the different language extensions [TT] . 

Summarizing, our library differs in a number of ways from other existing 
approaches: 

— First, along with more recent libraries it differs from early systems in that it is 
written entirely in Prolog. This dispenses with the need for a foreign interface 
and opens up more opportunities for automatic program transformation and 
analysis. The use of the meta-predicates setarg/3 and call/1 means that 
the use of Prolog has a minimal impact on performance. 

— Second, the library is designed as a set of separate modules. This allows 
replacing a performance-critical part — like the range code — with a new 
implementation better suited for it. 

— Third, the library supports the "glass-box" approach fully, encouraging the 
user to access directly the low-level layers for performance-critical code with- 
out losing the convenience of the high-level CLP paradigm. Again, the fact 
that the implementation is fully in Prolog is the main enabler of this feature. 

— Lastly, we have prioritized extensibility, ease of modification, and flexibility, 
rather than micro-optimizations and pure raw speed. However, we argue that 



our design will accommodate several key optimizations like the ones of |12j 
without needing to extend the underlying WAM. 

The rest of the paper proceeds as follows. In Sec.[3]we present the architecture 
of the library and the interface of the modules. In Sec. [3] we discuss with an 
example how to use the glass box approach at different levels for better efficiency 
in a particular problem, with preliminary benchmarks illustrating the gains. 
Finally, in Sec. [5] we conclude and discuss related and future work. 

2 Architecture of the Ciao CLP(:F£>) Library 

The Ciao CLP(J r 2?) library consists of seven modules grouped into three log- 
ical layers plus two specialized Prolog to Prolog translators. In the definition 
of these modules and interfaces we profit from Ciao's module system |13| and 
Ciao's support for assertions |14I4| . so that every predicate is correctly annotated 
with its types and other relevant interface-related characteristics, as well as doc- 
umentation. The translators are built using the Ciao packages mechanism |13) . 
which provides integrated and modular support for syntax modification and code 
transformations. A description of the user interface for the library along with 
up-to-date documentation may be found in the relevant part of the Ciao manual. 

2.1 The Global Architecture 

The global architecture is illustrated in Fig. [TJ The kernel layer provides facili- 
ties for range handling and propagation chains, which are used for defining finite 
domain variables — which, as mentioned before, are different from the stan- 
dard logical variables. The TT> layer defines a finite set of constraints such as 
a+b=c/3, using indexicals. These constraints are translated form their indexical 
form to a set of instructions of the kernel layer. Labeling and branch-and-bound 
optimization search modules complete the finite domain solver. 

The CLP(J r 2?) constraints are translated to TT> constraints by a CLP(J r 2?) 
compiler. We use attributed variables to attach a finite domain variable to every 
logical variable involved in CLP (J-T>) constraints. Thus, the CLP[TT>) layer is 
thin and of very low overhead. 

2.2 The Finite Domain Kernel 

The finite domain kernel is the most important part of the library. Its imple- 
mentation freely follows the design of the GNU Prolog TV solver ([8] provides a 
general overview of this solver) . A finite domain variable is composed of a range 
and several propagation chains. When the submission of a constraint modifies 
the range of a finite domain variable, other finite domain variables depending 
on that range are updated by firing up constraints stored in propagation chains. 
The propagation events are executed in a synchronous way, meaning that a range 
change will fail if any of its dependent constraints cannot be satisfied. 
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Fig. 1. The Ciao CLP(TV) Library Architecture. 



The kernel implements arithmetic over ranges (pointwise operations, union, 
intersection complementation, ...) and management of propagation chains, amount- 
ing to the delay of Prolog goals on arbitrary events. These two elements are used 
to implement the two basic operations of a finite domain variable: tell and 
prune. The first one attempts to constrain a variable into a particular range, 
while the second one (prune /2) removes a value form the range of a variable. 
The variable code inspects the new and old ranges and wakes up the suspended 
goals on a given variable. 

All the data structures are coded in an object-oriented style. Efficient access 
and in-place update are implemented by using the setarg/3 primitive. We took 
special care to use setarg/3 in a safe way to avoid undesired side effects, such 
as those described by Tarau |15) . 



Ranges. Range handling is one of the most important parts of the library, given 
the high frequency of range operations. Indeed, the library supports three imple- 
mentations for ranges: the standard one using lists of closed integer intervals; an 
implementation using lists of open (i.e., unbounded) intervals; and a bit-based 
implementation which despite allowing unbound ranges is more suitable for prob- 
lems dealing with small rangesH Indeed, the user is encouraged to implement 
new range modules which are better suited to some particular problems. 

3 The implementation of the bit-based range uses arbitrary precision integers plus 
three non-ISO predicates for computing the least and most significative bits, and 
the number of active bits in such integers. We implemented these predicates in C. 



:= t . . t (interval) 

{t} (singleton) 

r \/ r (union) 

r A r (intersection) 

- r (complementation) 

r + n (pointwise addition) 

r - n (pointwise subtraction) 

r * n (pointwise multiplication) 

:= min(Y) (minimum) 

max(Y) (maximum) 

dom(Y) (domain) 

val(Y) (value) 

t+t | t-t | t*t | . . . (arithmetic expression) 

n (bound) 

Fig. 2. Range Interface, Part 1: Syntax. 



The interface that a range module must implement is split into two parts. 
The first one, shown in Fig. [3J deals with range creation and manipulation. 
Each of the operations defined in the figure has a corresponding predicate. For 
instance, bounds addition t+t is implemented by the predicate bound_add/3, 
and similarly for the rest of the predicates. Note that it is a convention of the 
interface that any operation that tries to create an empty range will fail. This is 
better for efficiency and we found no practical example yet where this would be 
inconvenient. 

Fig. [3] lists the rest of the predicates that a range implementation must 
provide. They are mainly used for obtaining information about a range and 
are instrumental for the labeling algorithms. 



Propagation Chains. Propagation chains are just lists of goals meant to be 
executed when a change in the range of a TT> variable happens. The module 
defines a propagation chain structure that is simply a named set of chains. We 
support in-place update for the structure, thus allowing efficient update of the 
propagation chains used in the finite domain variables. The interface of the 



f d_range_bound_t / 1 
f d_range_t/l 
is_singleton/l 
singlet on_to_bound/2 
size/2 

get_domain/2 
enum/2 

bound_const/2 



Type of a range bound. 

Type of a range object. 

True if range is a singleton. 

Returns the value of a singleton range. 

Number of elements in a range. 

List of elements in a range. 

Backtracks throughout all the elements in a range. 
Correspondence of indexical constants with bounds. 



Fig. 3. Range Interface, Part 2: Predicates. 



f d_pchains_t/l Type of a chain structure. 

f d_pchain_type_t/l Name of a chain. 

empty/1 Returns an empty chain structure. 

add/3 Adds a goal to a given chain. 

execute/2 Wakes up a particular chain. 

Fig. 4. Propagation Chain Interface. 

propagation chain module is presented in Fig. 2) We use internal facilities of the 
Ciao module system in order to efficiently implement execute/2. 

Finite Domain Variables. An TV variable is a structure consisting of a range 
and a propagation chain. 

In the current implementation, integers are considered to be finite domain 
variables too. However, we are in the process of phasing out this optimization 
as we incorporate more information into finite domain variables to aid optimiza- 
tions. 

J-T> variables are never unified, i.e., they cannot be substituted by others or 
by integer values as is typically done by the Prolog unification mechanism. A 
priori, such variables have no correspondence to Prolog logical variables. 

Apart from accessing its range and propagation chain, the most important 
operations that a finite domain variable supports is the tell operation, which 
tries to update the TT> variable to a new range: 

tell_range(FdVar , TellRange) : - 

f d_var : get_range(FdVar , VarRange) , 

fd_range: intersect (VarRange, TellRange, NewRange) , 

set_range_and_propagate(FdVar , VarRange, NewRange) 

The propagation predicate will set the new range for the variable and compare 
the new range with the old one. The current definition — following |12) — sup- 
ports four propagation events, depending on the range change: 

dom: The range changed. 

max: The maximum of the range has changed, 
min: The minimum of the range has changed, 
val: The new range is a singleton. 

2.3 The Finite Domain Solver 

Once the finite domain kernel is in place, the finite domain solver is just the 
labeling algorithm and a set of constraints defined using the kernel. As mentioned 
before, the constraints are defined using indexicals, of the form X in Range. Such 
indexicals are compiled to programs of the TT> kernel in a transparent way for the 
user. The compilation is carried out by Ciao's source-to-source transformation 
capabilities, which means that an input Prolog file using the indexicals package 



is processed in such a way that predicates containing indexical definitions are 
replaced by their compiled form. 

The indexical syntax is intended to be compatible with syntax used in SIC- 
Stus and GNU Prolog. However, the use of Ciao's package system means that 
the user may freely mix indexicals with Prolog code (or with many other syntax 
extensions, such as, e.g., functional notation) without any ill effect, as seen in 
Appendix [A] 

The Constraints Library. A reasonable set of local constraints is provided, 
covering most examples that we have tried to date. We use the convention of 
using t for ground terms, such that in the constraint 'a+b<>c'/3, all three 
arguments are assumed to be TV variables, whereas in the constraint named 
a+t<>c/3, the second argument is assumed to be an immutable singleton, and 
thus no propagation chains will be installed on it. 

Labeling and Optimization Searches, This layer includes also typical label- 
ing algorithms and branch and bound optimization searches. In fact, the current 
labeling engine is a slight adaptation of the one in the SWI CLP (TV) library: we 
opted for replacing the preliminary version of the engine with this one from SWI, 
because of its many useful features and easy adaptability to our library^ The 
porting task was relatively easy because the labeling engine is a quite peripheral 
part of the library (i.e., it has very few code dependencies). It also underlines 
the high modularity of our library, since two versions of the labeling are in fact 
available 0. Finally we obtained for free a common user interface with SWI (and 
Yap). 

The optimization searches uses a branch-and-bound algorithm with restart 
to find a value that minimizes (or maximizes) the TV variable according the 
execution of a Prolog goal. It offers a user-interface similar to the one provided 
by GNU Prolog. 

2.4 CLP(TV) 

With the TV solver in place, supporting the CLP (TV) paradigm is a matter of 
performing two mappings: logical variables must be put in correspondence with 
TV variables and CLP(TV) constraints must be translated to TV constraints. 

Variable Wrapping. For every logical variable to be involved in a CLP(J r 2?) 
constraint we will attach to it an attribute containing an TV variable: 

4 Some features of this engine are currently disabled, but we are planning to activate 
all such features shortly. The labeling engine was in fact extracted from the tor 
library |16| . where it is isolated in a single file. 

5 The old labeling engine can be found in revisions older than 14721 of Ciao 1.15. 



1 wrapper(A, X):- get_attr_local(A, X), !. 

2 wrapper(A, X):- var(A), !, f d_term:new(X) , put_attr_local(A , X). 

3 wrapper(X, X):- integer(X) , !. 

Logical variables and finite domain variables may communicate in two ways. In 
the first one, two logical variables may be unified, needing to link their underlying 
finite domain variables. We implement this communication using the unif y_hook 
attribute: 

1 attr_unif y_hook(IdxVar , Other) : - 



2 ( nonvar (Other) -> 

3 ( integer(Other) -> 

4 f d_constraints: 'a=t ' (IdxVar, Other) 

5 ; clpf d_error(type_error(Other) , '='/2) 

6 ) 

7 ; get_attr_local(Other , IdxVar_) -> 

8 fd_constraints: ' a=b ' (IdxVar , IdxVar_) 

9 ; put_attr_local(Other , IdxVar) 
10 ). 



We simply call the TV constraints 'a=b'/2 and 'a=t'/2. 

The other form of communication is instantiation of the logical variable 
when the corresponding finite domain one gets a singleton range. We modify 
the wrapper predicate to add an instantiation goal to the val chain of freshly 
created TV vars, i.e., we replace the second clause within the definition of the 
wrapper by the following one: 

1 wrapper(A, X):- var(A), !, f d_term:new(X) , put_attr_local(A , X), 

2 % Force instantiation of A when X represents an integer 

3 f d_term: add_propag(X, val, 'fd_term: integerize' (X, A)). 

This small example points out the possibilities of our scheme beyond the current 
use as a support for indexicals. 

Constraint Compilation. The TV solver provides a finite set of TV con- 
straints, however, in the CLV(TV) side we may encounter constraints such as: 

1 A#=B+C+D+E 

which should be linearized to 

1 Al #= D + E, 

2 Bl #= B + C, 

3 A #= Al + Bl 

and then wrapped tojf| 

6 We profit here from Ciao's functional notation such that for p(X,Y), ~p(X) is han- 
dled syntactically like a function with return value Y. 



1 'a=b+c ' ("wrapper(Al) , "wrapper (D) , ~wrapper(E) ) , 

2 'a=b+c ' ("wrapper (Bl) , "wrapper(B) , "wrapper(C) ) , 

3 'a=b+c ' ("wrapper (A) , "wrapper(Al) , "wrapper(Bl) ) 



We provide a small compiler which takes care of this process, along with other 
features like compile-time integer detection. 

3 Glass-Box Programming 

As previously stated, we encourage the use of a glass box approach when pro- 
gramming with this library. We will use the classical queens program in order 
to illustrate some of the possibilities that the library offers: 

— The use of different range implementations. 

— The direct use of the TV constraints, skipping the CLP(J r I?) compiler. 

— The definition of new TT> constraints using indexicals. 

— The definition of new atomic constraints directly using the solver kernel, 
thus skipping the indexical compiler. 

Benchmarking Conditions: We provide for illustration purposes some prelimi- 
nary experimental results. However, it is important to point out that the library 
is not yet in a state in which relevant absolute performance numbers can be 
produced and its performance potential fully assessed, since it is still missing 
important optimizations. Also, only two benchmarks are used. 

The benchmarks were run using Ciao 1.15 (revision 14744) on an Intel(R) 
Core(TM)2 CPU T7200 @ 2.00GHz computer. For reference, we include also 
the corresponding numbers for SWI Prolog (v. 5.10.4). The purpose is not to 
make an extensive comparison^] but rather to have a simple, well understood 
baseline with which to compare. We should note that we did not explore SWFs 
support for custom constraints. At the same time, during these tests we have 
determined that backtracking over changes made by setarg/3 is currently sig- 
nificantly slower in Ciao than in SWI, which, given the reliance of the imple- 
mentation on setarg/3 gives us a clear avenue for performance improvement, 
independently of any changes to the library itself. 

The complete program used in the benchmark is shown in Appendix [AJ Basi- 
cally a benchmark has three run time parameters, the number of queens (n=N), 
the labeling strategy (either "step" or "first fail'Q), and the constraints used, 
whose meaning will be explained later. For SWI, only the first two parameters 
carry significance. 

7 This is left as future work where, in addition to implementing the optimizations 
mentioned, we will include comparison with a number of other systems as well. 

8 Comparing the Ciao and SWI libraries using the heuristic labeling strategies as "first 
fail" is relevant since both use the same code for labeling. 



Queens Parameters 


Bits 


Closed 


Open 


SWI 


n=16, step, clpfd 


0.916 


1.144 


1.432 


1.050 


n=16, step, fd 


0.572 


0.848 


1.104 




n=16, step, idx 


0.388 


0.648 


0.916 




n=16, step, kernel 


0.224 


0.336 


0.368 




n=90, ff, clpfd 


2.080 


2.052 


2.484 


1.071 


n=90, ff, fd 


1.112 


1.272 


1.592 




n=90, ff, idx 


0.752 


1.124 


1.588 




n=90, ff, kernel 


0.388 


0.408 


0.432 





Fig. 5. Queens Benchmark. 



3.1 Range Implementations 

As previously stated, the library provides three range implementations, selectable 
at compile-time. The standard one is called "Closed," and represents ranges using 
a Prolog list of intervals of integers. Thus, every TT> variable is always bound. 
"Open" is a variation of this approach where the intervals are enriched with 
constants sup and inf. This imposes a penalty on bound arithmetic. Lastly, we 
compare both against a simple bit- vector implementation, done mostly in Prolog 
with a small support from C. The results can be seen in Fig. [5J The differences 
go from negligible to more than 50%. In a different benchmark (bridge), the 
closed interval version was 25% faster than the open one. 



3.2 Constraint Implementations 

We now focus on the different possibilities that the library allows for TT> con- 
straint programming. 

In the queens program, the main constraint of the problem is expressed by 
the dif f /3 constraint: 

1 diff(X, Y, I) :- 

2 X #\= Y, 

3 X #\= Y+I, 

4 X+I #\= Y. 

where I will be always an integer. 

However, the compiler cannot (yet) detect that I is an integer, and may 
perform some unnecessary linearization. We may skip the compiler and define 
dif f using directly the TT> constraints: 

1 diff(X, Y, I):- 

2 fd_constraints: 'a<>b' (~w(X) ,~w(Y)) , 

3 fd_constraints: 'a<>b+t' (X, Y, I), 

4 fd_constraints: 'a<>b+t' (Y, X, I). 



The speedup is considerable, getting close to 50% speedup in some cases. Indeed, 
the compiler should be improved to produce this kind of code by default. 



The user may notice that the above three constraints may be encoded by 
using just two indexicals. For instance one can use the following definition for 
diff/3: 

1 diff (X,Y,I) :- 

2 idx_diff (~w(X) , ~w(Y) , I). 

3 idx_diff(X, Y, I) +: 

4 X in --Oal(Y), val(Y)+c(I), val(Y)-c(I)}, 

5 Y in --Oal(X), val(X)+c(I), val(X)-c(I)}. 

Again, the improvement is up to 40% from the previous version. 

However, the constraint diff can be improved significantly by using directly 
the kernel delay mechanism (val chain) and J-T> variable operations. In particu- 
lar, we use the optimized kernel prune/2 operation that removes a single element 
form the range of a variable: 

1 diff (X, Y, I) : - 

2 wrapper(X, XO) , wrapper(Y, Y0) 

3 f d_term: add_propag(Y, val, ' queens : cstr ' (XO, Y0, I)), 

4 f d_term: add_propag(X, val, ' queens: cstr ' (Y0, XO, I)). 

5 

6 % Y is always a singleton. 

7 cstr(X, Y, I):- 

8 f d_term: integerize(Y, Y0) , 

9 fd_term: prune (X, YO) , 

10 Yl is YO + I, 

11 f d_term: prune (X, Yl) , 

12 Y2 is YO - I, 

13 fd_term: prune (X, Y2) . 

We reach around 80% speedup from the first version, and this result is optimal 
regarding what the user can do. Additional speedups can be achieved, but not 
without going beyond our glass-box approach. Indeed, our CLP(J r P) compiler 
is simpler given that we are working on a new translator that directly generates 
custom kernel constraints from CLP(J-T)) constraints. 



4 Conclusions and Future Work 

The Ciao CLP(J r I?) library described is distributed with the latest Ciao version, 
available at |http : / / c iaohome . org. Although included in the main distribution, 
it lives in the contrib directory, as it should be considered at a beta stage of 
development. 

Even if we did not include yet important optimizations that should improve 
significantly the performance of the library, the current results are encouraging. 
The library has been used successfully internally within the Ciao development 
team in a number of projects. 



The modular design and low coupling of components allow their easy re- 
placement and improvement. Indeed, every individual piece may be used in a 
glass-box fashion. We expect that the use of Prolog will allow the integration 
with Ciao's powerful static analyzers. At the same time, the clear separation of 
run-time and compile-time phases allows the modification and the improvement 
of the translation schemes in an independent manner. Indeed, the advantages of 
this design have already been showcased in |17] . where a Prolog to Javascript 
cross-compiler was used to provide a JS version of the library and which only 
required replacing a few lines of code. Using this cross-compiler CLP(J r 2?) pro- 
grams can be run on the server side or on the browser side unchanged. 

Regarding future work, we distinguish two main lines: the kernel and the 
CLP(J"D) compiler. 

For the kernel, the first priority is to finish settling down its interface. While 
we consider it mature, some optimizations — like avoiding reexecution — may 
require that we include more information in our !FT> variable structure, range 
modification times, etc. Indeed, we would like to support more strategies for 
propagators than the current linear one. Support for some global constraints is 
on the roadmap, and will likely mean the addition of more propagation chains. 

The library features primitive but very useful statistics. However we think it 
is not enough and we are working on an TT> instrumentation package that will 
provide detailed statistics and profiling. This is key in order to extract the max- 
imum performance from the library. Once we get detailed profiling information 
from a wide variety of benchmarks, a better range implementation will be due. 

Regarding the CLP(7 r 2?) compiler, the current version should be considered 
a proof of concept. Indeed, we are studying alternative strategies including the 
generation of custom kernels or specialized TT> constraints for each particular 
program in contrast to the current approach of mapping a CLP(7 r 2?) program to 
a fixed set of primitive constraints. CiaoPP — Ciao's powerful abstract interpre- 
tation engine — could be used in the translation, providing information about 
the CLP(J r 2?) program to the CLP(FT>) compiler so it can generate an optimal 
kernel of J-T> code for that program. In this sense, we think that we will follow 
the CiaoPP approach of combining inference with user-provided annotations in 
the new CLP(J r X') compiler. 
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A Complete Code for the Queens Example 



1 queens (N, L, Lab, Const) :- 

2 length (L, N) , 

3 domain (L, 1 , N) , 

4 safe(L, Const) , 

5 labeling (Lab, L) . 
6 

7 safe([] , _Const) . 

8 safe([X|L] , Const) :- 

9 noattack(L, X, 1, Const), 
10 safe(L, Const). 

11 

12 noattack([], _, _, _Const) . 

13 noattack( [Y|L] , X, I, Const) :- 

14 diff (Const, X, Y, I), 

15 II is I + 1, 

16 noattack(L, X, II, Const). 
17 

18 diff(clpfd, X, Y, I) :- 

19 X #\= Y, X #\= Y+I, X+I #\= Y. 

20 

21 diff(fd, X,Y,I):- 

22 fd_diff ('wrapper (X) , ~ wrapper (Y) , I). 

23 

24 fd_diff(X, Y, I):- 

25 fd_constraints : 'aOb' (X,Y) , 

26 fd_constraints: 'a<>b+t' (X,Y,I) , 

27 fd_constraints : 'a<>b+t' (Y,X,I) . 

28 

29 diff(idx, X,Y,I):- 

30 idx_diff ("wrapper (X) , ~wrapper(Y), I). 
31 

32 idx_diff(X, Y, I) +: 

33 X in -{val(Y), val(Y)+c(I), val(Y)-c(I)}, 

34 Y in -{val(X), val(X)-c(I), val(X)+c(I)} . 

35 

36 diff (kernel, X,Y,I):- 

37 kernel_diff ("wrapper (X) , "wrapper (Y), I). 

38 

39 kernel_diff (X, Y, I) :- 

40 fd_term:add_propag(Y, val, 'queens : cstr ' (X, Y, I)), 

41 fd_term:add_propag(X, val, 'queens : cstr ' (Y, X, I)). 

42 

43 cstr(X, Y, I):- 

44 fd_term:integerize(Y, Y0) , 

45 fd_term: prune (X, Y0) , 

46 Yl is Y0 + I, fd_term: prune (X, Yl) , 

47 Y2 is Y0 - I, fd_term: prune (X, Y2) . 



